4章 エンコーディングと進化

バイナリエンコーディングの細部はアプリケーションの設計やデプロイの選択肢に影響する

バイナリエンコーディングの手法

いずれも前方・後方互換性

多くのサービスではサービスの新バージョンを一回に少数のノードを徐々にデプロイできれば、サービスをダウンタイムなしでデプロイできる。

後方互換性（新しいコードが古いデータを読める）と前方互換性（古いコードが新しいデータを読める）が保たれるようにエンコードされる必要がある

データフローの形態

データベース経由

データベースへの書き込みを行うプロセスがデータをエンコード、データベースからの読み取りを行うプロセスがそのデータをデコード

データベースへの保存処理は将来の自分自身へのメッセージ送信と考えると後方互換性が求められる

新しいバージョンのコードで書かれたデータベース中の値が古いバージョンのコードで後から読まれる可能性を考えると前方互換性も求められる

サービス経由

RPCとREST APIではクライアントがリクエストをエンコードし、サーバはそのリクエストをデコードしてレスポンスをエンコードして返す。最後にクライアントがレスポンスをデコードする

サービス内API間で互換性を保たなければならない

メッセージパッシングによるデータフロー

ノードはお互いにメッセージを送信することによって通信し、送信側がメッセージをエンコードして受信側がメッセージをデコードする

メッセージブローカー

ノード間でのメッセージを一時的に保存する中継地点

Apache kafka、Google Cloud Pub/Sub、Amazon MQなど

いくつかのメリットがある

受信側の負荷軽減によるシステムの信頼性向上

受信側のプロセスがクラッシュしても再送することでメッセージが失われるのを防ぐ

送信側が受信側のIPアドレスやポート番号を知る必要がないs

一つのメッセージを複数の受信側に送信できる